Mechanism for hardware configuration and software deployment

ABSTRACT

A plug-and-play solution deployment mechanism and infrastructure to automate deployment of network cluster devices is disclosed. The solution includes an agile hardware topology discovery mechanism to automatically map the hardware of the cluster devices. The solution includes an intelligent engine for recognition of BIOS configuration setting and BIOS configuration of the devices. The solution also includes a demand-driven Cloud architecture design engine to design and test a cloud architecture incorporating the cluster devices.

PRIORITY CLAIM

The present disclosure is a continuation of U.S. patent application Ser.No. 16/034,939 filed Jul. 13, 2018, which claims priority to U.S.Provisional Ser. No. 62/532,748, filed on Jul. 14, 2017. The contents ofthose applications are hereby incorporated by reference in theirentireties.

TECHNICAL FIELD

The present disclosure relates generally to efficient electronic deviceand network provisioning. More particularly, aspects of this disclosurerelate to automation of provisioning devices to set up clustereddevices.

BACKGROUND

The emergence of the cloud for computing applications has increased thedemand for off-site installations, known as data centers, that storedata and run applications accessed by remotely connected computer deviceusers. Such data centers typically have massive numbers of servers,switches, and storage devices to store and manage data. A typical datacenter has physical rack structures with attendant power andcommunication connections. The racks are arranged in rows throughout theroom, or rooms, of the data center. Each rack may hold multiple devicessuch as servers, switches, and storage devices. As different functionsare requested by operators of data centers, specialized servers arerequired. Such specialized servers may include a storage server, acomputing server, a graphic processing unit server, or a network switchserver. Connecting each of the servers in the rack to switching devicesfor communication is time consuming. Further, each type of server in anetwork for a data center requires different setups of hardware andsoftware.

Each type of device must be installed in a rack or cluster that may havea variety of desired nodes, such as computer servers, controllerservers, and storage servers, for example. The management and dataswitches that connect all the nodes in a rack must be connected andproperly configured so each node may communicate data to each other. Theindividual operating systems on each rack node must also be configured,and any specialized software must be installed. Finally, the connectionsand functions of the nodes must be validated. Thus, setup of a rack orcluster of nodes for a data center is often a time consuming andmanually intensive endeavor.

The traditional deployment method for preparing a cluster of nodes foroperation is considerably complicated. A large amount of manual tasks isrequired prior to the deployment process. For example, switchconfiguration, hardware information collection, and BIOS setup must beperformed by technicians for each network and node in the cluster.Further, solution prerequisites and configurations need to be definedfor each network and node after hardware information is collectedmanually. After deployment, several validation tests need to be manuallyexecuted on the deployed solution for a functional check of thesolution.

One example of the complexity relates to composing systems to operateunder a Cloud infrastructure. Operators are looking for ways toconstruct their cloud infrastructure correctly to prevent costly repairsand trouble shooting. However, to precisely compose a system forOpenStack cloud environment is not feasible due to the lack ofcollecting hardware topology, especially on non-uniform memory access(NUMA) balanced design hardware. Operators always encounter difficultiesin identifying hardware component allocation in current introspectionprocesses provided by Ironic or Maas, which does not include hardwaretopology information. Lack of hardware topology information duringinstallation will cause certain problems. For example, it is oftendifficult to identify the connection between the network interface cards(NIC)s and the corresponding slots when user installs more than one NICcard to a system.

Another complicated issue is adjusting BIOS configuration setting duringinstallation. Traditionally, to alter a BIOS setting, users need toapply a BIOS change through either baseboard management controller (BMC)console redirection, or physically go on-site and have a keyboard andmonitor connected to a server for examination of the BIOS settings. Suchprocedures are time consuming and inefficient.

Another issue is the challenge of planning and designing an OpenStackcloud architecture. Such architecture is always challenging and requiresdeep understanding of OpenStack services, user requirements, anddetailed hardware design. Administrators currently spend a lot of timedigging into OpenStack services, deciding which machine model to use,and learning how to select all of the configurations based on thehardware layout. Currently some open-source projects have attempted toimplement automation aimed at facilitating the OpenStack clouddeployment. However, such projects only focus on the software deploymentpart of OpenStack cloud deployment.

As demonstrated by the examples above, current solution deployment fornetworked devices is a time-consuming job and may result in numeroushuman errors. Thus, there a need for a streamlined process to allow forcomposition of systems for network based operation. There is a furtherneed for a flexible BIOS configuration mechanism to allow for automaticadjustment of BIOS settings for networked devices. There is also a needfor a system for efficient planning of an OpenStack cloud servernetwork.

SUMMARY

One disclosed example is a method for configuring the basic input outputsystem (BIOS) of nodes in a networked cluster. A connection isestablished between a deployment server and each of the nodes. Thedeployment server is operable to access a plurality of stored differentoptions for BIOS configurations. At least one of the accessible BIOSoptions is selected for at least one BIOS configuration for each of thenodes via an intelligent engine based on a predefined rule. The BIOS foreach of the nodes is configured according to the selected BIOS option.

Another disclosed example is a system to automatically configure thebasic input output system (BIOS) of nodes in a networked cluster. Thesystem includes a deployment server connected via the network to each ofthe nodes in the cluster. A BIOS configuration file includes a pluralityof stored accessible options for BIOS configurations. An intelligentengine is operable to select at least one of the accessible BIOS optionsfor at least one BIOS configuration for each of the nodes, via anintelligent engine based on a predefined rule. The intelligent engineconfigures the BIOS for each of the nodes according to the selected BIOSoption.

The above summary is not intended to represent each embodiment or everyaspect of the present disclosure. Rather, the foregoing summary merelyprovides an example of some of the novel aspects and features set forthherein. The above features and advantages, and other features andadvantages of the present disclosure, will be readily apparent from thefollowing detailed description of representative embodiments and modesfor carrying out the present invention, when taken in connection withthe accompanying drawings and the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure will be better understood from the following descriptionof exemplary embodiments together with reference to the accompanyingdrawings, in which:

FIG. 1A is a block diagram showing the process of automaticconfiguration of a cluster or rack of devices;

FIG. 1B is a screen image of an example solution configuration file;

FIG. 2 is a flow diagram of the deployment of solutions to automaticallyconfigure a solution;

FIG. 3A is an example of switch components on a rack connected todeployment server;

FIG. 3B are the switch components and different ports for connection torack components;

FIG. 4A is a flow diagram of an example method for automatic discoveryof network hardware;

FIG. 4B is a flow diagram of an example alternative method for automaticdiscovery of network hardware;

FIG. 4C is a screen image of the results of a hardware discovery processto show discovered hardware information;

FIG. 4D is an example database NIC table schema for BMC IP assignment;

FIG. 4E is a screen image of a MAC address table dump;

FIG. 4F is a screen image of a 4.f mapping table;

FIG. 4G is a screen image of collected hardware topology data from oneexample node;

FIG. 5 is a block diagram of the architecture for an example intelligentBIOS configuration process;

FIG. 6 is a flow diagram of the process of configuring a BIOS for anetworked node;

FIG. 7A-7D are screen images of the menus for configuring a BIOS for anetworked node;

FIG. 8 is an example set of tables of hardware topography data of nodesin a rack system;

FIGS. 9A-9B are a flow diagram of a deployment plan providing templatesfor cloud based deployment;

FIG. 10A is a screen image of a back end log for the deployment ofnetwork configurations;

FIG. 10B is a screen image of a back end log for an Ansible playbook forsolution deployment;

FIGS. 11A-11E are screen images of user displays to displayconfiguration information for a network of devices;

FIG. 12A-12H are screen images of user interfaces that allow a user toenter network requirements; and

FIG. 13 is a screen image of a status user interface that shows thestatus of each of the steps of the process outlined in FIG. 2.

The present disclosure is susceptible to various modifications andalternative forms. Some representative embodiments have been shown byway of example in the drawings and will be described in detail herein.It should be understood, however, that the invention is not intended tobe limited to the particular forms disclosed. Rather, the disclosure isto cover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS

The present inventions can be embodied in many different forms.Representative embodiments are shown in the drawings, and will herein bedescribed in detail. The present disclosure is an example orillustration of the principles of the present disclosure, and is notintended to limit the broad aspects of the disclosure to the embodimentsillustrated. To that extent, elements and limitations that aredisclosed, for example, in the Abstract, Summary, and DetailedDescription sections, but not explicitly set forth in the claims, shouldnot be incorporated into the claims, singly or collectively, byimplication, inference, or otherwise. For purposes of the presentdetailed description, unless specifically disclaimed, the singularincludes the plural and vice versa; and the word “including” means“including without limitation.” Moreover, words of approximation, suchas “about,” “almost,” “substantially,” “approximately,” and the like,can be used herein to mean “at,” “near,” or “nearly at,” or “within 3-5%of,” or “within acceptable manufacturing tolerances,” or any logicalcombination thereof, for example.

The below described systems and methods are centered around aplug-and-play solution deployment mechanism and infrastructure toautomate deployment of network cluster devices in environments such asOpenStack architecture. FIG. 1A shows a process 100 of setting up anetwork of devices for a rack or cluster system 150. The desired devicesare installed in the rack 150 in the desired order and cables areattached (110). A web interface is generated for selected prerequisitesto provisioning the environment by a deployment server (112). As will bedescribed below, the process is centered around a plug and play managerfor provisioning a network of devices. The plug-and-play managerincludes three modules in this example: (a) an “Agile Hardware TopologyDiscovery Mechanism” module; (b) an “Intelligent Recognition for BIOSConfiguration Setting” module; and (c) a “Demand-driven CloudArchitecture Design Engine” module.

As shown in FIG. 1A, after hardware preparation, the plug-and-playmanager initiates the switch configuration process, automaticallydiscovers hardware, and launches the BIOS configuration process via ahardware orchestrator module (114). The management switch and dataswitches for a rack are thus configured. Subsequently, a prerequisiteshandler 116 starts to collect hardware information, and a media accesscontrol (MAC) address dump process is executed to retrieve data based onsolution requirements. Meanwhile, an OS provisioning process and anorchestrator installation process are implemented in this stage. Theplug-and-play manager initiates the solution configuration generationprocess via a solution deployment module 118 to compile environmenttemplates for deployment. Finally, the deployment and validation processis automatically launched (120).

Thus, the process 100 is directed toward set up and testing of devicesin the rack system 150. The rack system 150 includes at least onemanagement switch 152 and at least one data switch 154. As shown in FIG.1A, the hardware orchestrator 114 provides configuration of the switches152 and 154. The rack system 150 also includes a series of nodes 156,which may be computing servers, storage servers, or controller servers.The solution deployment module 118 provides configuration of the nodes156.

FIG. 2 shows a flow diagram for the topology discovery process executedby a solution deployment server 200. In this example, the solutiondeployment server 200 may execute the plug-and-play manager thatincorporates the “Agile Hardware Topology Discovery Mechanism, the“Intelligent Recognition for BIOS Configuration Setting” and the“Demand-driven Cloud Architecture Design Engine” modules Of course otherdevices may perform these functions as directed by the plug-and-playmanager.

A first stage is performed by the “Agile Hardware Topology DiscoveryMechanism” module to assist a user to discover the NUMA hardwaretopology. The plug-and-play manager hosts a DHCP service for thebaseboard management controller (BMC) and network interface of solutionnodes on the devices in the rack. The service populates a database withthe BMC addresses and MAC addresses for each node. The program imports asolution profile to the system. A solution profile is a set of data forconfiguring the solution based on customer demand and information fromthe database. For example, a solution profile for an OpenStack solutiondeployment may contain the total number of nodes; network IP subnets andVLANs for each network; and the storage environment settings, includingidentifying which disk to store data. FIG. 1B shows a screen image of anexample yaml file that includes MAC address, node name, BMC address andnode capability for each node. The yaml file in FIG. 1B is the set ofdata prepared based on customer specification obtained via a survey anddata obtained via a script that parses and filters the database entriesrelating to MAC addresses and BMC addresses.

The plug-and-play manager loads a switch profile to the data switches(202) and the management switches (204) through a COM port. The switchprofile contains data such as IP, VLAN, and LACP, data. A switchprofile, or a switch configuration file, is a file that defines the IPof the switch, the VLAN range accepted for each port, and the portbonding settings, as will be explained below. Once the properconfiguration file is generated, the plug-and-play manager loads theswitch profile to the designated switch through a COM port. In thisexample, there are two kinds of switches in the OpenStack solution,management switches and data switches. The management switch providesnetwork access to each BMC of each node. The data switch providesnetworking in the OpenStack solution and network access to the Internet.Each type of switch requires a switch profile to define the capabilityof each port.

When AC power is connected to the rack, the BMCs of each rack node willbe powered on automatically, and each will send a DHCP request to thedeployment server 200. The plug-and-play manager assigns an InternetProtocol (IP) address to each of the BMCs of all nodes on the rack 150in FIG. 1A. The plug-and-play manager collects the hardwareconfiguration for all of the nodes (206). The plug-and-play managercollects the MAC and IP addresses of all of the BMCs of all of the nodesand dumps a management switch MAC address table to a log file (208). Theplug-and-play manager parses the entries of the log file and thenimports the organized data to a database that is used for the solutionprofile as explained above (210). The plug-and-play manager thenprepares an inventory file. An inventory file contains detailedinformation for all of the network nodes, including the BMC IPaddresses, usernames, passwords, and MAC addresses of the NIC cards. Theinventory file also specifies the role of each node role (based on the“Demand-driven Cloud Architecture Design Engine” module).

The plug-and-play manager associates the server role and port mapping,and then starts an unattended BIOS configuration program for all nodes.The plug-and-play manager can identify each server attached to eachmanagement switch port as well as the IP of the BMC of each node. TheBIOS for all of the nodes is configured via the configuration program(214). As will be explained below, an interface generated by theplug-and-play manager allows for different BIOS configurations to beapplied to the nodes based on user input. Further, the interface allowsa user to apply a specific BIOS configuration for a group of nodes, asingle node or every node. After the BIOS is configured for all of thenodes in the rack system 150, the deployment server 200 powers on all ofthe nodes.

All the nodes of the cluster report hardware information, including diskdrive names, network interface name, hardware topology, and BMCinformation, to the plug-and-play manager. The plug-and-play managerpulls down node information from a database and then builds templatesfor solution deployment. The solution deployment program powers on thedirector node to a pre-boot execution environment (PXE) boot, and thenstarts bare metal provisioning (216). In this example, the boot isperformed from the network interface card of the director node. The BIOSreads the firmware on the option ROM (OPROM) of the NIC, and thenexecutes the code to boot the director node. The director node thensends a DHCP PXE request to the deployment server 200 (218)

When receiving the PXE request, the plug-and-play manager checks thedatabase setup to map each machine role and then updates thecorresponding bootstrap for each node. The deployment server 200responds to the DHCP client arch request from each client node (220).Client nodes may be operated in a legacy mode (222) or a unifiedextensible firmware interface (UEFI) mode (224). The deployment server200 instructs the client to load a corresponding boot program per theclient arch code. The deployment server 200 checks the DHCP user class(226) sent by each individual client node. If the user class is not iPXE(226), the deployment server 200 notifies the client node to load a iPXEboot loader (Undionly.kpxe) to execute (232). The client node thenre-sends the DHCP request with the iPXE user class to the deploymentserver 200 (226). If the client node sends the iPXE user class to thedeployment server 200, the deployment server 200 checks the client rolevia the client MAC address (230).

The deployment server 200 then loads a corresponding solution deploymentmodule to start solution provisioning. If an OpenStack module (234) ischosen, the plug-and-play manager starts to prepare the director node(236). Alternatively, solution provisions may be provided forsoftware-defined storage (SDS) solutions such as Ceph and Gluster. Thus,the process may be used for Ceph, Gluster, or OpenStack deployment. Thedeployment server 200 then determines whether the node is a directornode (236). If the node is a director node, the deployment server 200causes an image restore, where a required system will be set up on thedirector node (238). The director node is then rebooted (240). TheOpenStack cluster is then deployed (242). The deployment server 200 thenruns the cluster validation (244).

The solution deployment program starts with validation of the racksystem, including functional and load tests for the deployed solution.Each of the modules shown in FIG. 1A will be described in detail below.

The assembly of a rack involves the initial connection of cabling 110 inFIG. 1A. FIG. 3A shows an example deployment server 300, a managementswitch 302, and a data switch 304. The deployment server 300 includes aCOM1 port 310, a COM2 port 312, a RJ45 port 314, and a small form-factorpluggable (SFP)+ port 316. The management switch 302 includes a COM port320 and a RJ45 port 322. The data switch 304 also includes a COM port330 and a SFP port 332.

As shown in FIG. 3A, during initial hardware preparation, a cable isinstalled to connect the COM1 port 310 of the deployment server 300 tothe COM port 320 of the data switch 304. The data switch 304 is used forserving server data via a network on the rack.

During the initial hardware preparation, a cable is installed to connectthe COM2 port 312 of the deployment server 300 to the COM port 330 ofthe management switch 302. The management switch 302 handles theoperational data from baseboard management controllers on the nodes inthe rack. The configuration of the management switch 302 is deployedthrough the COM2 port 312.

Any available RJ45 port of the deployment server 300, such as the RJ45port 314, is connected by a cable to the last RJ45 port 322 of themanagement switch 302. This connection is made for node BMC IPassignment. Any available SFP+ port of the deployment server 300, suchas the SFP port 316, is connected via cable to the last SFP+ port 332 ofthe data switch 304. This connection is made for node hardwareinformation collection and topology information collection.

The remaining nodes, such as computing nodes, storage nodes, andcontroller nodes are mounted on the rack. Network cables are connectedbetween management switch 302 and a BMC network port for each node, inaccordance with a predefined cabling policy. Network cables areconnected from the data switch 304 and ports of network interface cardsfor each node, in accordance with the predefined cabling policy.

FIG. 3B shows an example of ports for cable connection between themanagement switch 302, the data switch 304, and nodes in the rack. Themanagement switch has a series of controller node ports 360, a series ofcomputing node ports 362, a series of software storage node ports 364,and a director node port 366. In this example, the storage node portsare Ceph protocol ports. The ports 360, 362 and 364 are connected toports for communication of the BMCs of controller nodes, computingnodes, and storage nodes respectively. The port 366 is connected to aport for communication with the BMC of a director node. The data switch304 also includes controller ports 370, computing ports 372, storageports 374, and a director port 376. The ports 370, 372, and 374 areconnected to the NICs of controller nodes, computing nodes, and storagenodes respectively. The port 376 is connected to the NIC of the directornode. As explained below, the management switch 302 and the data switch304 are connected to the deployment server 300 in FIG. 3A.

The system 100 (in FIG. 1A) allows for automatic identification ofhardware topology that assists a user to map the logical device name andphysical location of each rack node. Thus, the system 100 allows a userto identify whether selected hardware is a NUMA-balanced design, andthus there is no need to inspect the hardware block diagram manually forsolution deployment. The system 100 enables a user to easily associatelogical device names and physical locations without physically having toexamine the node. This mechanism can reduce the complexity of hardwareinformation location. The system enables a user to know each NIC namefor automatic software provisioning such as through an automationplatform for workflow control, such as Ansible, without booting theoperating system of the node.

The system 100 may use two methods to achieve the automaticidentification of hardware in step 206 in FIG. 2. Both methods leveragethe PCI configuration space setup with the intelligence to discover NIClogical device names to assist a user to locate the designated NIC,without involving an operating system.

A flow diagram of the first method is shown in FIG. 4A. The flow diagramin FIG. 4A outlines a process of discovery without firmware change. APCI configuration space scan is run to find the association between PCIecards, PCI bridges, and NUMA nodes in the system (400). The slotinformation for the PCI bridge is extracted from the system managementBIOS (SMBIOS) (402). If slot information is not available, the processreturns to run a PCI configuration space scan (400). The processdetermines whether PCI slot information is listed in the SMBIOS (404).If the PCI device class is not a PCI bridge (slot), the process returnsto run a PCI configuration space scan (400). The process then determineswhether there are any devices attached to the bus (406). If no devicesare attached, the process returns to run a PCI configuration space scan(400). The device function of the PCI bridge bus is used as a key toassociate the PCI configuration space with SMBIOS data. The process thenuses the PCI configuration space setup to discover the NIC display nameand the NUMA domain in the operating system (408). For example, theprocess may use “vid” and “did” to search a PCI database for the devicedisplay name. The process may use a bus number to identify the deviceNUMA domain. For example, on a two CPU socket system, a bus address 0x01to 0x7f is for NUMA 0, and a bus address 0x80 to 0xff is for NUMA 1.This process then allows processed data to be updated to the database.The information in the database allows a user to select appropriatenodes from a pool of nodes.

FIG. 4B shows the second method that relates to discovery with a changein the firmware. A BIOS 450 is coupled to a shared memory 452 that canbe accessed by the baseboard management controller, such as a baseboardmanagement controller 454, for each node. The BIOS 450 dumps PCIconfiguration space to the shared memory 452 for access by the BMC 454.The BIOS 450 also dumps SMBIOS information to the shared memory 452 foraccess by the BMC 454. The process pulls down the PCI configurationspace and SMBIOS data, and feeds the configuration space and data to anapplication 456 to perform data computation. The NIC display name in theoperating system is discovered according to the PCI configuration spacesetup. The updated processed data is stored to the database for nodecomposition.

FIG. 4C is a screen image 470 of a data readout showing the discoveredNIC information. The screen image 470 shows the NIC name 472, a MACaddress 474, a physical location 476, and a hardware name 478, that areeach discovered from the PCI configuration space setup. For example, theLinux “IP address” command returns the NIC name and MAC address, whilethe PCT bus number of the PCI end device is used for NUMA domainlocation. The physical location may be obtained by locating the PCIbridge associated with the specified PCI end device and the check bridgedisplay name from the SMBIOS.

FIG. 4D shows an example database NIC table schema that is used in thecollection of MAC/IP address step 206 in FIG. 2. The information in thetable may be used for user friendly location and device information,hardware topology for solution planning, and obtaining MAC addresses forsolution deployment. When the BMC of a node is powered on, it will senda DHCP request to any available DHCP server such as the deploymentserver 200 in FIG. 2. When the deployment server 200 receives the DHCPrequest, it assigns an IP address to the BMC of the node. The BMCapplies the assigned IP address to itself and sends an acknowledgment tothe deployment server 200.

The user may browse the deployment user interface, and then input anetwork ID and IP address for the management switch setup. Thedeployment user interface may be generated by the deployment server 200or any web-capable device accessible to the user. The deployment server200 runs a network switch configuration program to apply the designatedIP address to the management switch. The designated IP address is sentto the management switch, such as the management switch 302 in FIG. 3,through the COM1 port of a deployment server. such as the deploymentserver 300 in FIG. 3, or the deployment server 200 in FIG. 2.

The deployment server 200 sends ICMP requests to all host IDs on a BMCprovisioning network. The deployment server 200 then runs a program todump the MAC address table from the management switch. FIG. 4E is ascreen image of a MAC address table dump.

The deployment server 200 then runs another program to generate a BMC IPand management switch port mapping table. The deployment server 200 thenassigns an alias IP address to the NIC port on the deployment server 200that is used for BMC orchestration. The deployment server 200 then runsa program to change the BMC IP of all nodes according to a 4.f mappingtable. FIG. 4F is a screen image of a 4.f mapping table that may be usedfor BMC provisioning. For example, if the default DHCP network ID is10.102.50.0/24, and the default IP address for the deployment server 200default is 10.102.50.254, the IP address of the BMC that is connected tomanagement switch port 1 is 10.102.50.28. In order to change the IPaddress of the BMC from 10.102.50.28 to 172.16.0.11 from the deploymentserver 200, the deployment server 200 must be enabled to reach bothnetworks. Thus, an alias IP 172.16.0.254 is assigned to the deploymentserver 200.

After the IP and MAC addresses are collected and compiled in the mappingtable, the deployment server 200 will power down all of the nodes. Thedeployment server 200 will then send a power-on command to all nodes inthe rack system. The deployment server 200 then instructs all nodes toboot into a mini-OS for node information collection. At this point,hardware topology, NIC name, and physical location mapping will becollected by one of the methods outlined in FIGS. 4A-4B above. Thedeployment server 200 will run a program to dump the MAC address tablefrom the data switch, such as the data switch 304 in FIG. 3, through theCOM2 port of the deployment server into a database on the deploymentserver 200.

FIG. 4G is a screenshot of an example collected hardware topology datafor one node. FIG. 4G shows that node 12 has four network cardsinstalled. Some of the network cards are dual-port NIC and some of themare single port NIC. The first line of the screenshot in FIG. 4Gindicates that the BMC NIC of the node is connected to port 11 of themanagement switch, and the assigned IP address is 172.16.0.21.

As explained above, the process also includes intelligent recognitionfor BIOS configuration settings in a rack system, as shown in step 214of FIG. 2. The intelligent recognition for BIOS configuration settingmay be an intelligent engine, which is a software defined BIOSconfiguration deployment to recognize BIOS configuration settings andautomatically select such settings. This mechanism will help a user tochange BIOS configurations according to predefined rules processed bythe intelligent engine to prevent human errors. The intelligent engineis executed by the deployment server 200 via the plug-and-play manager.

FIG. 5 is a block diagram of a system architecture 500 of theintelligent recognition routine for BIOS configuration. The systemarchitecture 500 includes a BIOS configuration file 510. The BIOSconfiguration file 510 is read by a controller 520. The controller 520includes an intelligent data processing engine module 522 and a controlmodule 524. The intelligent data processing module 522 and controlmodule 524 are connected via a data channel 530 to a system under test(SUT) 540. The control module 524 sends control commands to the systemunder test 540. Console outputs from the system under test 540 arereceived by the intelligent data processing module 522.

FIG. 6 is a flow diagram of the process of intelligent recognition forBIOS configuration described above with reference to in FIG. 5. A userfirst enters a desired BIOS configuration into a user-defined template(600). The controller 520 determines whether the configuration is thelast entry of the nodes in the rack (602). If the configuration is thelast entry, then the process will stop. If the configuration is not thelast entry, the controller 520 loads in configuration data from the BIOSconfiguration file 510 to the intelligent data processing module 522.The controller 420 establishes a connection with the SUT 540. Thecontroller 520 reads data from the data channel 530.

The intelligent data processing module 522 may include different controllogic objects, including a menu control logic 610, an item logic 612, asub item logic 614, and a value logic 616. The controller 520 checks theinput from the user, and feeds the data to the one of control logicobjects 610, 612, 614, or 616 to perform data comparison via theintelligent engine 522.

If the data is a menu logic 610, the intelligent engine 522 determineswhether a backup file exists (620). If a backup file does not exist, theintelligent engine 522 creates a backup file and sets a flag to indicatethat the routine is processing the initial output (622). If a backupfile exists, the intelligent engine 522 compares the output from thesystem under test 540 and determines whether the output is the same asthe backup file (624). If the output is the same, the intelligent engine522 terminates the process with an error (626). If the output is not thesame, the intelligent engine 522 determines whether the best match isfound (628). If the best match is found, the intelligent engine 522enters the value and loops back to the next entry from the BIOSconfiguration file (602). If the best match is not found, theintelligent engine will send the arrow right and try to search the nextavailable menu. The intelligent engine will then loop back to comparingthe output to the backup file (624).

If the data is an item logic 612, the intelligent engine 522 determineswhether the counter is zero (630). If the counter is zero, theintelligent engine 522 creates a backup file (632). The intelligentengine 522 then sets the counter to one (634). If the counter is notzero, the intelligent engine 522 sets the counter to one (634). Theintelligent engine 522 then compares the output from the system undertest 540 and determines whether the output is the same as the backupfile (636). If the output is the same, the intelligent engine 522terminates the process with an error (626). If the output is not thesame, the intelligent engine 522 determines whether the best match isfound (638). If the best match is found, the intelligent engine 522enters the value and loops back to the next entry from the BIOSconfiguration file (602). If the best match is not found, theintelligent engine will send the arrow down and search the nextavailable item. The intelligent engine 522 will then loop back tocomparing the output to the backup file (638).

If the data is a sub-item logic 614, the intelligent engine 522determines whether the counter is zero (640). If the counter is zero,the intelligent engine 522 creates a backup file (642). The intelligentengine 522 then sets the counter to one (644). If the counter is notzero, the intelligent engine 522 sets the counter to one (644). Theintelligent engine 522 then compares the output from the system undertest 540 and determines whether the output is the same as the backupfile (646). If the output is the same, the intelligent engine 522terminates the process with an error (626). If the output is not thesame, the intelligent engine 522 determines whether the best match isfound (648). If the best match is found, the intelligent engine 522enters the value and loops back to the next entry from the BIOSconfiguration file (602). If the best match is not found, theintelligent engine will send the arrow down and search the nextavailable sub-item. The intelligent engine 522 will then loop back tocomparing the output to the backup file (648).

If the data is a value logic 616, the intelligent engine 522 determineswhether the counter is zero (650). If the counter is zero, theintelligent engine 522 creates a backup file (652). The intelligentengine 522 then sets the counter to one (654). If the counter is notzero, the intelligent engine 522 sets the counter to one (654). Theintelligent engine 522 then compares the output from the system undertest 540 and determines whether the output is the same as the backupfile (656). If the output is the same, the intelligent engine 522terminates the process with an error (626). If the output is not thesame, the intelligent engine 522 determines whether the best match isfound (658). If the best match is found, the intelligent engine 522enters the value and loops back to the next entry from the BIOSconfiguration file (602). If the best match is not found, theintelligent engine will send the arrow down to search for the nextavailable value. The intelligent engine 522 will then loop back tocomparing the output to the backup file (658).

Thus, the controller 520 retrieves a system under test (SUT) consoleoutput for the corresponding logic and compares the output with thebackup file. If the result is different, the system loops back for thenext entry in the configuration file. If the result is the same, theBIOS configuration process is terminated, and an error condition iscreated. This process is repeated until all BIOS configurations areapplied. The process then terminates the BIOS configuration process withreturn code 0. The intelligent engine 522 utilizes the intelligence tocollect the current console output from the SUT 540 and then startscomparing these outputs with a user defined string. If the intelligentrecognition engine 522 cannot find the specified data, it will search apredefined database for the related keyword. For example, if a userenters a search for the term “boot menu” but the current BIOS only has amenu called “BIOS setup,” the intelligent engine 522 will change thesearch pattern to BIOS setup.

In this example, a user needs to specify the terms “menu,” “item,”“subitem,” and “value” to find the specified string. Alternatively, auser may only need to specify an item and a value for data searching.The menu and sub-item can be discovered by the intelligent engine 522.The intelligent engine 522 will be able to find the best route to thedesired item in the database on the deployment server 200. Eachdifferent item and value combination will have a score, and the highestscore will constitute the best route. For example,key:menu:boot-item:boot mode value:legacy has a score of 7, whilekey:menu:boot-item:boot order value:usb has a score of 5. When a userspecifies “boot:legacy,” the program will know that a user is lookingfor menu:boot, item:boot mode, and value:legacy.

FIG. 7A is a screen image of an input interface 700 that may accept userselections for configuring a BIOS in accordance with the processdescribed in FIGS. 5-6. The input interface 700 includes an informationbox 702 that includes explanations for selected logic and a command keybox 704 that includes definitions for key strokes.

In this example, the input interface 700 includes a menu selection field710. The menu selection field 710 includes a boot configuration field712, a setup prompt time out field 714, and a quiet boot field 716. Inthis example, the setup prompt time out field 714 has been selected, anda user may input the number of seconds for a time out. In this example,the information box 702 includes instructions about the default (5seconds) and the range of values that a user may enter.

The input interface 700 includes item fields and value fields. Forexample, the input interface 700 shows a boot mode select item field 720and corresponding value fields 722. In this example, the item field 720includes boot options and corresponding values. For example, the firstboot option is the hard disk, the second boot option is a network slot,and the third and fourth boot options are disabled. For example, otherboot options such as a removable memory device that may be inserted intoa USB port, may be made available. The input interface 700 also includesdifferent subitem fields, such as a USB drive BBS priorities subitemfield 730, a network drive BBS priorities subitem field 732, and a harddisk drive BBS priorities field 734. Selection of a subitem allows auser to set the priorities for the boot device. For example, if thereare four hard disk drives on the system that may be used as theoperating system drive, then the hard disk drive BBS properties sub-menumay be used to define the boot order of the hard disk drives. Forexample, the hard disk drive boot order can be disk 2, then disk 3, thendisk 1, and finally disk 4. As for the boot option for a hard diskdrive, the menu only provides the default hard disk drive to the user tochoose. In this example, disk 2 would thus be the only one option forhard disk boot shown on the interface.

FIG. 7B shows a screen image of a pop up window 750 of the inputinterface 700 that shows the selection of one of the options under theitem field 732 (in FIG. 7A). Thus, a user has selected the Network DriveBBS properties and all available network interface cards, which may beused for a network boot as shown in the pop up window 750. FIG. 7C showsa screen image of the pop up window 750 with another option selected.Thus, a user has selected the second boot option shown in the pop upwindow 750. FIG. 7D shows logs of the BIOS configuration deploymentprogram.

As explained above, the deployment system 100 in FIG. 1A providesoverall solution deployment to setup and plan a cloud architecture fromhardware to software layer. The system will design the softwarearchitecture, according to the hardware layout that is collected from anagile hardware topology discovery mechanism, and a series of customerrequirements via design engine. The design engine (termed a“Demand-driven Cloud Architecture Design Engine”) may be executed on thedeployment server or another device. The design engine deploys theOpenStack cloud environment automatically without human intervention.

The design engine may be divided into an architecture designer moduleand a solution deployment module. The architecture designer moduledesigns the deployment plan by collecting customer requirements from auser interface. The collected customer requirements involve defining thetotal number of nodes in the designated cluster. The overall workloadfor each computing node or whole cluster, for example, is defined. Forexample, requirements may include the following: (a) each computing nodeshould be able to support least 20 virtual machines (VM)s, and the wholecluster should be able to support at least 200 VMs; (b) each VM shouldhave at least 20 GB of disk space, 8192 GB memory, 6 vCPUs with CPUpinning, 2 single root input/output virtualization (SR-IOV) NICs across2 physical NICs, and 1 management NIC with associated floating IP; (c)the overcommit ratio should be at most 8.0; and (d) the overallarchitecture should support high availability in networking.

The customer requirements may also define other cluster relatedsettings. For example: (a) the architecture should support highavailability in networking; (b) the architecture should support highavailability in storage; (c) the architecture should support highavailability in disk (e.g., enable a RAID to set up two disks as asingle logical device for the backup); and (d) the architecture shouldhave two provider networks with SR-IOV support. Other required settingsare collected, such as the network IP/subnet/VLAN assignment. Thisinformation may be provided by customers based on their productionenvironment.

The engine then collects the hardware topology of the rack or cluster asexplained above. FIG. 8 shows an example of a set of tables 800 of theresults of the collection of hardware topology. In this example, a table810 includes hardware topology data for Node 1; a table 820 includeshardware topology data for Node 2; and a table 830 includes hardwaretopology data for Node 3. As shown in the tables 810, 820, and 830 inFIG. 8, the CPU cores, RAM size, NIC ports, and disk size are collectedfor each of the computing nodes.

FIGS. 9A-9B show a decision workflow of a cloud architecture designengine design deployment plan based on the aforementioned requirements.FIGS. 9A-9B show that the example design deployment plan is divided intothree parts: (1) a storage template generation process 910; (2) anetwork template generation process 912; and (3) an overall templategeneration process 914.

In the storage template generation process 910, the architecturedesigner will first generate templates based on total disk capacityrequired (920). The process will check if a customer requested to enablehigh availability (HA) (922). If HA is enabled, the total number ofstorage nodes is refined to accommodate high availability (924). Inorder to deploy the OpenStack solution, it is necessary to identify howmany storage nodes are expected for the solution. First, the requiredstorage space is calculated based on customer requirements. For example,in Ceph storage systems, three replications for each data file is madeby default. Thus, the required storage space is multiplied by at least 3or more, depending on customer requests, and then calculated for thetotal number of storage node requires. In order to fulfill highavailability, there will be a minimum of three storage nodes in thiscase. Thus, the system shall remain functional even if one or more ofthe storage node crashes. After the total number of storage nodes isrefined, or if the customer did not request enabling HA, the processdetermines whether there is a customer request to adjust the number ofreplications (926). If there is a customer request, the Ceph OSD journalratio is refined (928). The OSD is the storage daemon for Ceph storage.It is responsible for storing objects on a local file system andproviding access to them over the network. The journal is where data isinitially written before it is flushed to an OSD. The OSD journal ratiodefines how many OSD(s) will be controlled by one single journal disk.The storage template is one of the configuration files for OpenStackdeployment. A OSD-journal map is configured in the storage template. Ifthere is a customer request, the value in the storage template isadjusted in accordance with the request. After refining the CephOSD-journal ratio, or if there is no customer request for replications,the process outputs the storage deployment plan having the requirednumber of storage nodes and Ceph OSD journal ratio (930).

In the network template generation process (914), the architecturedesigner will first generate templates based on the total number of NICports (940). The process then checks if there is a customer request toenable HA (942). If there is a customer request for HA, the templatesare refined to enable cross-NIC port bonding (944). Network bonding, orlink aggregation, is a technology that combines multiple networkconnections/NICs in parallel to increase throughput or provideredundancy. Cross-NIC port bonding includes selecting one of the NICports from 2 different NICs and configuring then as a network bond. Inthis case, the network connection shall remain functional even if one ofthe NICs, one of the ports, or one of the network cables is broken.After refining the template, or if there is no customer request for HA,the process checks if the customer request includes having single rootinput/output virtualization (SR-IOV) support (946). If there is acustomer request, the SR-IOV feature and design related VLANconfigurations are enabled (948). As explained below, this configurationchange will also be fed back as an item in overall template generationprocess (914).

After the SR-IOV feature and VLAN configurations are enabled, or ifthere is not customer request, the process checks if a customerrequested to have data plane development kit (DPDK) support (950). Ifthe customer requested DPDK support, the process enables the DPDKfeature and design related VLAN configurations (952). This configurationchange will also be fed back as an item in the overall templategeneration process (914). After enabling the DPDK feature, or if thecustomer did not request the DPDK feature, the process outputs thenetwork deployment plan with appropriate cross-NIC port bonding, SR-IOVsupport, DPDK support, and VLAN configurations (954).

The overall template generation process 914 mainly focuses on controllernode design and CPU core allocation strategy. The architecture designerwill first generate templates based on the total number of vCPUsrequired and total cores for each node (960). The process checks ifcustomer requested enabling HA (962). If the customer request for HA wasmade, the process refines the total number of controller nodes (964).Ordinarily, only a minimum of one controller node is required. However,if HA is requested, a minimum of three of controller nodes is required.In this case, the OpenStack control plane will remain functional even ifone or more of the controller nodes crashes. After refining the totalnumber of controller nodes, or if the customer has not requestedenabling HA, the process checks if the customer requested a specificnetwork environment such as SR-IOV or DPDK from the network templategeneration process 912 (966). If the customer requested a specificnetwork environment, the process refines the CPU allocation strategy(968). The overall template is one of the configuration files forOpenStack deployment. There are several CPU allocation lists that aredefined for either VM or DPDK host processes. If a customer requests aDPDK network on the OpenStack solution, CPU cores are allocated for DPDKprocesses to use. If this is not the case, the CPU allocation list isset only for host processes and virtual machines (VM)s. After refiningthe CPU allocation, or if the customer has not requested a specificnetwork environment, the process outputs the overall deployment planthat includes the total number of controller nodes and CPU allocation(968).

The hardware topography data from the tables shown in FIG. 8 maydetermine solution role tagging that may be performed by the deploymentserver 200 in FIG. 2. For example, the deployment server may collect thenumber of each node for the roles defined in the storage templategeneration 910, the network template 912, and the overall template 914.For example, based on the templates, the desired numbers of controllernodes, computing nodes, and storages node may be 1 each.

Once the desired numbers of nodes are determined, the deployment server200 tags a role for each node in the cluster. From the table 830 in FIG.8, Node 3 has only 2 NICs but has 73 TB of available disk space, andthus Node 3 is tagged as a storage node. The hardware components arebasically the same between Node 1 and Node 2, as shown by the tables 810and 820. However, Node 2 has a larger RAM size. Thus, Node 2 is taggedas a computing node, and Node 1 is tagged as a controller node. Once theroles are tagged for each node, the tagged roles are updated back to thedatabase in the deployment server 200.

The solution deployer handles the overall deployment process to buildthe designated OpenStack cloud environment. After the architecturedesigner finishes the deployment plan, the solution deployer generatesrequired deployment templates; provisions the operating system andregister system to official channels; and deploys overall solutionsautomatically. FIG. 10A shows a backend log generated by the deploymentof the configurations from the templates generated using the process ofFIGS. 9A-9B based on the deployment plan. FIG. 10B is a standard backend log for an OpenStack solution deployment, such as an Ansibleplaybook for the solution deployment.

The plug-and-play manager of the deployment server 200 may generate auser interface to guide a user through the provisioning and deploymentprocess for a cluster or rack of devices. A user imports a configurationfile generated by a user interface. When the file is imported andsubmitted, a user configuration interface is displayed by the deploymentserver 200. FIGS. 11A-11E shows screen images of a configurationinterface 1100 allowing the selection of the cluster switch, network,and overcloud configurations. As may be seen in FIG. 11A, theconfiguration interface 1100 includes a status bar 1102 that includesfour informational displays, a general information display 1110, aswitch configuration display 1112, a director and control plane networkdisplay 1114, and an overcloud display 1116. Each of the stages 1110,1112, 1114, and 116, when selected, generates an informational display.A series of control buttons 1118 (back and confirm & next) allow a userto navigate between displays.

In FIG. 11A, the general information display 1110 has been selected, anda general information display 1120 is displayed. The general informationdisplay 1120 allows a user to confirm the selected SKU and node countinformation. The general information display 1120 thus includes asummary information field 1122, a switch information field 1124, adirector node (infra) field 1126, a controller node information field1128, a DPDK/SR-IOV compute node information field 1130, and a storagenode information field 1132. These fields include information about thehardware for each of the nodes and switches. The information may includetypes of CPUs, ports, RAM, NICs, storage, and node quantity. The display1120 also includes an architecture map 1134 representing the layout ofthe nodes and switches for user reference.

FIG. 11B shows the selection of the switch configuration display 1112,which results in displaying a switch configuration display 1140. Theswitch configuration display 1140 allows a user to confirm the switchconfiguration. In this example, the graphic representing a singlemanagement switch is displayed. However, if the system includes multiplemanagement switches, graphics representing the multiple managementswitches may be displayed. The switch configuration display 1140includes a ports chart 1142 that has a key 1144 showing the type of nodeconnected to each port in the chart 1142. The switch configurationdisplay 1140 includes a table 1146 that includes information for eachnode, including port number, BMC IP, BMC network, BMC gateway, and therole of the node.

FIG. 11C shows the selection of the director and control plane networkdisplay 1114, which results in displaying a director and control plannetwork display 1150. The director and control plane network display1150 allows a user to confirm the network settings of the OSP directornode and control plane network. The display 1150 includes a directorsettings field 1152 that includes the IP address of the director node.The display 1150 includes a control plane network field 1154 thatincludes information such as addresses for the control plane network.

FIGS. 11D-11E shows the selection of the overcloud configuration display1116, which results in displaying an overcloud configuration display1160. The overcloud configuration display 1160 allows a customer toconfirm the network settings of an OpenStack solution. FIG. 11D showsthe selection of a network setting option 1162. A network summary table1164 is thereby displayed that shows each network name, VLAN name,Classless Inter-Domain Routing (CIDR) address, staring IP range, andending IP range. FIG. 11E shows the selection of a NFVi settings option1172. A summary table 1174 is thus displayed that shows the Single RootI/O virtualization (SR-IOV) number of virtual functions (VF)s, andcorresponding VLAN ranges as well as the DPDK corresponding VLAN ranges.

FIGS. 12A-12F show a series of screen images of a configurationinterface 1200 that allows for configuration of the hardware in thenetwork system by a user. As may be seen in FIG. 12A-12B, theconfiguration interface 1200 includes a status bar 1202 that includesfive stages, a select solution SKU stage 1210, a configure cluster stage1212, a configure OSP Director stage 1214, a configure OSP overcloudstage 1216, and a review settings stage 1218. A user may navigatebetween interfaces using a direction key(s) 1204. Each of the stages1210, 1212, 1214, 1216, and 1218, when selected, generates a selectioninterface.

FIGS. 12A-12B show the selection of the select solution SKU stage 1210that results in the display of a select solution interface 1220. Thesolution interface 1220 displays a hardware map 1222 and a descriptionfield 1224. The hardware map 1222 shows the cloud platform architecturefor reference. The description field 1224 includes detailed informationon selected devices shown in the hardware map 1222.

FIG. 12C shows the selection of the configure cluster interface stage1212 that causes a configure cluster interface 1220 to be displayed thatallows a user to enter expected workload requirements used by thetemplates generated by the process in FIGS. 9A-9B. The configure clusterinterface 1220 includes overall work load selection fields 1222, VMflavor fields 1224, HA guarantee fields 1226, and a node count field1228. The over workload selection fields 1222 allow a user to select thenumber of virtual machines per node and per cluster. The VM flavorfields 1224 allows a user to select the disk size; memory size; vCPUsize; whether the CPUs in the cluster provide CPU pinning; and thenumbers of SR-IOV provider networks, if a SR-IOV network is required.The HA guarantee fields 1226 allow a user to choose whether to enable HAfeatures in terms of network, storage, and disks. The node count field1228 shows the number of allocated nodes, which allows a user to setnodes for Ceph storage, DPDK and SROV functions. The node count field1228 also lists the number of controller and director nodes

FIG. 12D shows the selection of the configure OSP Director stage 1214that causes an OSP Director interface 1230 to be displayed. OSP is a redhat OpenStack solution and the OSP director can be regarded as itsorchestration for OSP deployment. The interface 1230 allows a customerto enter the network subnet/VLAN information for the OSP undercloud,which is able to fit in their own environment.

FIG. 12E shows the selection of the configure OSP Overcloud stage 1216that causes an OSP Overcloud interface 1240 to be displayed. The OSPovercloud may be regarded as the OpenStack solution to bedesigned/deployed by the system. The interface 1240 includes a networksettings selection 1242 and a NFVI settings selection 1244. The networksettings selection 1242 allows a user to enter network subnet/VLANinformation for an OpenStack solution which is able to fit in their ownenvironment. The user may also choose whether to use VLAN or VxLAN intheir environment. Once the user clicks to edit the information of anetwork type, a pop up window 1250 shown in FIG. 12F will open. The usercan enter related information, including network CIDR, VLAN ID, andallocation pool values for the OpenStack solution. Returning to FIG.12D, the NFVI settings selection 1244 allows a user to enter VLAN rangeand related settings for SR-IOV and DPDK networks, via a SR-IOV settingsarea 1252 and a DPDK settings area 1254 FIGS. 12F-12G show the selectionof the configure review settings stage 1218 that causes a reviewsettings interface 1260 to be displayed. The review settings interface1260 allows a user to review and double check all of the settingsentered in FIGS. 12A-12E. The review settings interface 1260 displaysthe SKU configurations, switch settings, configuration of the OSPdirector, and the OSP overcloud. The reviews settings interface 1260include a download button 1270 that when selected, downloads the enteredconfigurations file, which is imported to the solution deployer runningon the deployment server 200 in FIG. 2.

FIGS. 12G-12H show the selection of the configure review settings stage1218 that causes a review settings interface 1260 to be displayed. Thereview settings interface 1260 allows a user to review and double checkall of the settings entered in FIGS. 12A-12D. The review settingsinterface 1260 displays the SKU configurations, switch settings,configuration of the OSP director, and the OSP overcloud. The reviewssettings interface 1260 include a download button 1270 that whenselected, downloads the entered configurations file, which is importedto the solution deployer running on the deployment server 200 in FIG. 2

The flow diagrams in FIGS. 2, 6, and 9 are representative of examplemachine readable instructions for the deployment server 200 in FIG. 2 toprovide the correct software and hardware configuration for a racksystem. In this example, the machine readable instructions comprise analgorithm for execution by: (a) a processor; (b) a controller; and/or(c) one or more other suitable processing device(s). The algorithm maybe embodied in software stored on tangible media such as flash memory,CD-ROM, floppy disk, hard drive, digital video (versatile) disk (DVD),or other memory devices. However, persons of ordinary skill in the artwill readily appreciate that the entire algorithm and/or parts thereofcan alternatively be executed by a device other than a processor and/orembodied in firmware or dedicated hardware in a well-known manner (e.g.,it may be implemented by an application specific integrated circuit[ASIC], a programmable logic device [PLD], a field programmable logicdevice [FPLD], or a field programmable gate array [FPGA], discretelogic, etc.). For example, any or all of the components of theinterfaces can be implemented by software, hardware, and/or firmware.Also, some or all of the machine readable instructions represented bythe flowcharts may be implemented manually. Further, although theexample algorithm is described with reference to the flowchartsillustrated in FIGS. 2, 6, and 9, persons of ordinary skill in the artwill readily appreciate that many other methods of implementing theexample machine readable instructions may alternatively be used. Forexample, the order of execution of the blocks may be changed, and/orsome of the blocks described may be changed, eliminated, or combined.

As used in this application, the terms “component,” “module,” “system,”or the like, generally refer to a computer-related entity, eitherhardware (e.g., a circuit), a combination of hardware and software,software, or an entity related to an operational machine with one ormore specific functionalities. For example, a component may be, but isnot limited to being, a process running on a processor (e.g., digitalsignal processor), a processor, an object, an executable, a thread ofexecution, a program, and/or a computer. By way of illustration, both anapplication running on a controller, as well as the controller, can be acomponent. One or more components may reside within a process and/orthread of execution, and a component may be localized on one computerand/or distributed between two or more computers. Further, a “device”can come in the form of specially designed hardware; generalizedhardware made specialized by the execution of software thereon thatenables the hardware to perform specific function; software stored on acomputer-readable medium; or a combination thereof.

The terminology used herein is for the purpose of describing particularembodiments only, and is not intended to be limiting of the invention.As used herein, the singular forms “a,” “an,” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. Furthermore, to the extent that the terms “including,”“includes,” “having,” “has,” “with,” or variants thereof, are used ineither the detailed description and/or the claims, such terms areintended to be inclusive in a manner similar to the term “comprising.”

Unless otherwise defined, all terms (including technical and scientificterms) used herein have the same meaning as commonly understood by oneof ordinary skill in the art. Furthermore, terms, such as those definedin commonly used dictionaries, should be interpreted as having a meaningthat is consistent with their meaning in the context of the relevantart, and will not be interpreted in an idealized or overly formal senseunless expressly so defined herein.

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample only, and not limitation. Numerous changes to the disclosedembodiments can be made in accordance with the disclosure herein,without departing from the spirit or scope of the invention. Thus, thebreadth and scope of the present invention should not be limited by anyof the above described embodiments. Rather, the scope of the inventionshould be defined in accordance with the following claims and theirequivalents.

Although the invention has been illustrated and described with respectto one or more implementations, equivalent alterations and modificationswill occur or be known to others skilled in the art upon the reading andunderstanding of this specification and the annexed drawings. Inaddition, while a particular feature of the invention may have beendisclosed with respect to only one of several implementations, suchfeature may be combined with one or more other features of the otherimplementations as may be desired and advantageous for any given orparticular application.

Although the invention has been illustrated and described with respectto one or more implementations, equivalent alterations and modificationswill occur or be known to others skilled in the art upon the reading andunderstanding of this specification and the annexed drawings. Inaddition, while a particular feature of the invention may have beendisclosed with respect to only one of several implementations, suchfeature may be combined with one or more other features of the otherimplementations as may be desired and advantageous for any given orparticular application

1-20. (canceled)
 21. A method for configuring the basic input outputsystem (BIOS) of nodes in a networked cluster, the method comprising:establishing a connection between a deployment server and each of thenodes, wherein the deployment server is operable to access a pluralityof stored different options for BIOS configurations, wherein each of theBIOS configurations includes a BIOS boot specification order for aplurality of hard drives on the node and a BIOS boot specification orderfor a plurality of network devices accessible by node; selecting atleast one of the accessible BIOS options for at least one BIOSconfiguration for each of the nodes via an intelligent engine based on apredefined rule; and configuring the BIOS for each of the nodesaccording to the selected BIOS configuration option.
 22. The method ofclaim 21, wherein the BIOS configuration is a boot up source.
 23. Themethod of claim 22, wherein the corresponding BIOS options include amemory on the node, a removable memory device, and a network storagedevice.
 24. The method of claim 21, further comprising generating aninterface on a display, the interface including the plurality of optionsin the order, the interface including an input mechanism to select oneof the plurality of options.
 25. The method of claim 23, wherein theinterface includes a selection input to allow a user to select a BIOSconfiguration for at least one of the nodes, and wherein the predefinedrules follow the selected BIOS configuration.
 26. The method of claim25, wherein the selection input includes at least one of a menu, anitem, a subitem or a value.
 27. The method of claim 25, wherein thedeployment server includes BIOS configuration files including theplurality of files, and wherein based on the selection input, thedeployment server searches the BIOS configuration file for a matchingfile to the selection input.
 28. The method of claim 27, wherein thepredetermined rules include a default BIOS option for the BIOSconfiguration if a match between the selection input and BIOSconfiguration file is not found.
 29. The method of claim 25, wherein theinterface includes a selection input to allow a user to select a BIOSconfiguration for a group of nodes, a single node or every node.
 30. Themethod of claim 21, further comprising comparing the selected BIOSoption with an existing BIOS option of each of the nodes, and leavingthe existing BIOS option if the selected BIOS option is the same as theexisting BIOS option.
 31. A system to automatically configure the basicinput output system (BIOS) of nodes in a networked cluster, the systemcomprising: a deployment hardware server connected via the network toeach of the nodes in the cluster; a storage device storing a BIOSconfiguration file including a plurality of stored accessible optionsfor BIOS configurations, wherein each of the BIOS configurationsincludes a BIOS boot specification order for a plurality of hard driveson the node and a BIOS boot specification order for a plurality ofnetwork devices accessible by the node; an intelligent engine operableto: select at least one of the accessible BIOS options for at least oneBIOS configuration for each of the nodes via an intelligent engine basedon a predefined rule; and configure the BIOS for each of the nodesaccording to the selected BIOS configuration option.
 32. The system ofclaim 31, wherein the BIOS configuration is a boot up source.
 33. Thesystem of claim 32, wherein the corresponding BIOS options include amemory on the node, a removable memory device, and a network storagedevice.
 34. The system of claim 32, further comprising a display coupledto the deployment server, wherein the deployment server generates aninterface on the display, the interface including the plurality ofoptions in the order, and an input mechanism to select one of theplurality of options.
 35. The system of claim 34, wherein the interfaceincludes a selection input to allow a user to select a BIOSconfiguration for at least one of the nodes, and wherein the predefinedrules follow the selected BIOS configuration.
 36. The system of claim35, wherein the selection input includes at least one of a menu, anitem, a subitem or a value.
 37. The system of claim 35, wherein based onthe selection input, the deployment server searches the BIOSconfiguration file for a matching file to the selection input.
 38. Thesystem of claim 35, wherein the interface includes a selection input toallow a user to select a BIOS configuration for a group of nodes, asingle node, or every node.
 39. The system of claim 31, wherein theintelligent engine is operable to compare the selected BIOS option withan existing BIOS option of each of the nodes, and leaves the existingBIOS option if the selected BIOS option is the same as the existing BIOSoption.